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MANAGEMENT OP APPLICATION PROGRAMMING INTERFACE 
INTEROPERABILITY 

ABSTRACT 

5 

A computer system development tool for managing interoperability between client applications and 
server applications in differing APIs. The tool includes source code sample files having an index 
section, a conditional statement section, and a subroutine section. Each source code sample files is 
defined in a language conforming to one of the APIs. The subroutines in a source code sample file 
10 define by example the interoperability of the source code sample API with other APIs. The source 
code sample file conditional statement section sets out the varying interoperability constraints and 
the index permits a developer to locate sections of the source code sample rile of interest for a given 
interoperabtUty issue. 
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MANAGEMENT OF APPLICATION PROGRAMMING INTERFACE 
INTEROPERABILITY 

field or tee imxynQN 

The present invention is directed to an improvement in computing systems and in particular to an 
5 improvement in the management of application programming interface imeroper&bility, 

BACKGROUND OFTWK INVENTION 

In a distributed computing environmeni; it is typical for a server application to be written using & 
particular application programming interface (API), while client applications may be written using 
a different API. Different APIs may provide different levels of support for their respective 
10 application systems. In addition, some APIs may support a given feature of me back end application 
system, but may not provide full interoperability with other APIs for other application systems in 
use in a heterogeneous client server context. 

It is common that a system developer implements a computer system using an application with a 
defined API on a client system for interaction with a specified API on a server system. In such a 
15 case, API interoperability issues may arise. The developer typically relies on documentation 
provided with the APIs in question to determine the level of interoperability available and to develop 
computer code for the client API which conforms to the interoperability constraints which may exist 
for the different APIs. 

Problems with this approach include the necessity for the programmer to consult different 
20 documentation sources, and the unwieldy and potentially unclear manner in which information 
pertaining to the interoperability of different APIs is presented. 

Prior art systems have been described which include automated approaches to permit for 
mteropexabihty between heterogeneous systems. For example, for object-oriented systems one such 
system is described in U.S. Patent 5,732,270, Foody et al. The system includes object-oriented 
25 frameworks for defining proxy objects so mat objects from a differing object-oriented environment 
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may oc usea as u mey wercnative oojeco in me environment ot a given prSy object Such a 
system is defined to operate dynamically to permit objects to be manipulated by manipulating the 
proxy object in a different environment. There is a complex set of frameworks defined to permit 
such a proxy object to be defined and used. Another such system permitting interoperability 
between applications is disclosed in U S. Patent 5.913,061, Gupta et aL This system requires an 
interchange server for transferring messages between connectors in respective appUcatioiis and a 
defining the interoperability of the applications. Such approaches require a system to be installed 
and dynamically interact with the APIs to handle the interoperability between APIs, Alternative 
systems rely on the automated generation of source code based on detailed definitions of interface 
and communication information or script sources (see for example; Japanese Patents JP 11073306 
and JP1 11 19986). 

It is therefore desirable to have a tool to permit application programming interface interoperability 
to be managed efficiently without the need for a developer to research different interoperability 
information, to invoke a system to dynamically interact with the APIs, or to require detailed formal 
definitions to be created as a precondition to the automated generation of source code. 

SUMMARY QFTttE flWEHTTON 

According to one aspect of the present invention, there is provided improved management of 
application programming interface interoperability. 

According to another aspect of the invention, there is provided a computer system development tool 
for managing the interoperability of differing application program interfaces, the computer system 
including a source code sample file written for a first application program interface and including 
subroutines defining successful interoperation with a second application program interface. 

According to another aspect of the invention, there is provided the above computer system 
development tool in which the source code sample file further includes a conditional statement 
section including source code reflecting the applicability of the subroutines in the subroutine section 
to the permutations of client application program Interface and server application program interface 
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uTleroperarion, and an index section including entries referring to the source code logic blocks in the 
conditional statement section. 

According to another aspect of the invention, there is provided a computer system development tool 
for managing the interoperability between a set of client applications and a set of server applications 
5 where each of the set of client applications, and each of the set of server applications, is written to 
conform to a selected one of a set of application program interfaces! the computer system 
development tool including a collection of source code sample files, each of the source code sample 
files conforming to a target one of the set of client application program interfaces and including 

a subroutine section having subroutines exemplifying successful interopfiration between the 
target client application program interface and each of the set of differing server application 
program interfaces, 

a conditional statement section including source code reflecting the applicability of the 
subroutines in the subroutine section to the permutations of client application program 
interface and server application program interface interoperation, and 

an index section including an index of the subroutines in the subroutine section. 

According to another aspect of the invention, there is provided the above computer system 
development tool further including a set of server side source code files for interaction with the 
subroutines of the source code sample files to demonstrate the wteroperation of the subroutines of 
the source code sample files with the server application program interfaces. 

20 According to another aspect of the invention, there is provided a computer program product 
including a computer usable medium having computer readable program code means embodied in 
said medium for use in managing the interoperability between a set of client applications and a set 
of server applications where each of the set of client applications, and each of the set of server 
applications, is written to conform to a selected one of a set of application program interfaces, said 

25 computer program product having computer readable program code including a collection of source 
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code sample files, each of the source code sample files conforming to a target one of the set of client 
application program interfaces and including 

a subroutine section having subroutines exemplifying successful intcro Deration between the 
target client application program interface and each of the set of differing server application 
program interfaces, 

a conditional statement section, including source code reflecting the applicability of the 
subroutines in the subroutine section to the permutations of client application program 
Interface and server application program interface interoperation, and 

an index section including an index of the subroutines in the subroutine section. 

According to another aspect of the invention, there is provided the above computer program product, 
the computer readable program code further including a set of server side source code files for 
interaction with the subroutines of the source code sample files to demonstrate the inleroperation of 
the subroutines of the source code sample files with the server application program interfaces. 

Advantages of the present invention include the ability for a developer to manage mteroperability 
issues between different application programming interfaces by accessing a library of 
interoperability source code which may be tested out and used to construct systems which avoid 
mteroperability conflicts. 

aurar nrarRiPxioN of rm urawtnos 

The preferred embodiment of the invention is shown in the drawings, wherein: 

Figure 1 is a block diagram showing potential interaction between example' APIs for clients 
and servers. 

Figure 2 is a block diagram showing the structure of a source code sample file, according to 
the preferred embodiment of the invention. 
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la the drawings, the preferred embodiment of the invention is illustrated by way of example. It 
to be expressly understood that the description and drawings are only for the purpose of iUustration 
and as an aid to understanding, and are not intended as a definition of the limits of the invention. 

DETAILED DESCRIPTION tiff T*m P REFERRED EMBODIMENT 

3 Figure 1 is a block diagram illustrating the potential interaction between different client and servo- 
APIs, Boxes 10, 12, 14 represent API implementations for API 1, API 2, API 3, respectively, for 
client applications. Similarly, boxes 16, 18, 20 represent server applications having APIs 1 , 2, 3, 
respectively. As is shown by the lines connecting the various client APIs, 10, 12, 13 to the server 
APIs 16, 18, 20 for the 3 APIs shown as examples in Figure I. there are 9 possible connections 
l o between the 2 sets of three applications. 

Where, for example, a system developer seeks to write an application using client API 2 (box 1 2), 
to communicate with server API 3 (box 20), the application developer must consult documentation 
which sets out potential interoperability issues arising from the interaction of programs written in 
accordance with the two different APIs. 

1 5 According to the preferred embodiment, a set of source code sample files is created for the APIs of 
interest. The structure of on example source code sample file for an API is shown in the example 
block diagram of Figure 2. Figure 2 shows the source code sample file having an index section 22, 
a conditional statement section 24 and a subroutine section 26. 

According to the preferred embodiment, the source code sample file for a given API provides a set 
20 of sample source code subroutines defining interoperability techniques to be adopted by a system 
developer encoding the client system for the given API. 

For example, for a back end application system which is a relational database management system, 
it is typical to provide access by way of stored procedures. Turning to the example of Figure I , 
where a developer is developing a client system in API 1, the developer will make use of the 
25 provided source code sample file written for that API (API 1 ). The API 1 source code sample file 
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contains subroutines written in API 1 which model the successful calls to stored procedures as 
implemented in API 2, for example, on the server systems for the relational database management 
system (RDBMS). 

In the source code sample files provided in the preferred embodiment, index 22 includes references 
to interoperability issues relating to the potential stored procedure calls available for the RDBMS. 
Index 22 permits the developer to locate statements found in conditional statement section 24 of me 
source code sample file. Conditional statement section 24 is defined in the language of API 1 and 
includes logic that reflects the interoperability constraints imposed by code written for API 1 
accessing server systems that use API 2 or API 3. In other words, a series of statements (typically 
including a number of conditional statements such as IF statements) indicate whether interoperability 
is possible, and if so the name of a source code sample subroutine provided in the sample file for the 
APIs in question is provided. Where a statement in conditional statement section 24 makes reference 
to a subroutine, the subroutine is defined in subroutine section 26 of the source code sample tile, for 
the example referred to above. The subroutines in subroutine section 26 include sample calls to the 
stored procedures available in the API 2 and API 3 implementation of the RDBMS. 

Once a system developer has located the appropriate subroutine in the source code sample file shown 
in Figure 2, the developer is able to copy the subroutine to the developer's source code file (written 
for API 1) and to make the appropriate modifications to the subroutine to match the needs of the 
developer in defining the client system implementation. 

In this way, the system developer need not consult documentation tables setting out interoperability 
characteristics relating to the APIs of interest, but is able to effectively and simply move to the 
implementation of subroutines which will provide interoperability between the client implemented 
using the API for the client side and the server system implemented using the API for the server 
system. 

In addition, in the preferred embodiment, source code is also provided for the server side to 
implement a sample server function. In this way, it is possible to execute the subroutines in the 
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source code sample file on a sample server implementation. The ability to run me sample source 
codes on both the client side and the server side permits the developer to confirm that the subroutines 
provided in the source code sample file work in the environment in which the developer is 
implementing the desired client system 

5 Although the above example is described with reference to a database back end system and to stored 
procedure access to that database back end system, it will be understood by those skilled in the art 
that the approach of the preferred embodiment permits source code sample files to be created for any 
set of desired APIs relating to specified application systems. 

An example of how the sample source code file of the preferred embodiment is used in 
10 implementing an SQU API client application (embedded SQL in Java) ling an SQL stored 
procedure on the server side called MY_NEWJ»ROC, is given below. 

According to the preferred embodiment, an SQLJ source code sample file is provided. The 
developer will be able to use the index in the SQLJ sample source code file (corresponding to index 
22 shown in Figure 2). In the example presented here, the index contains the following 2 entries 
l s (amongst other entries relating to other interoperability issues): 

outParameter: return median salary of EMPLOYEE table 
Parameter types used: OUT DOUBLE 

OUT INTEGER 

OUT CHAR(32) 

20 decimalTypc: pass and receive a DECIMAL data type from a stored 

procedure 

Parameter types used: INOUT DECIMAL 

These entries in the index indicate that the outParameter subroutine and the deci malType subroutine 
are subroutines relating to parameter passing. In the example presented here, the stored procedure 
25 named MYNEW_PROC written in SQL returns OUT parameters having double, decimal, integer 
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ami char (255) data types. The outPararneter and decimalType subroutines are therefore of interest 
to the developer. The developer therefore searches the conditional statements section of the SQU 
source code sample file (shown as section 24 in Figure 2) to locate the statements relating to these 
two subroutines. Example entries in the conditional statement section are presented below: 

5 //All server APIs can pass OUT parameters. 

//All server APIs support DOUBLE, INTEGER, 
//and CHAR date types. 
outMedian «= outParsmeter(con); 

//Java and SQL procedures can handle DECIMAL data types 
»0 if OangWe.triinO-e(nials("SQL") || 

laneuage.tlim0.equais("JAVA• , )) 

{ ■ 

decimalType(con); 

} 

As will be seen, the conditional section in this example indicates that all server APIs support data 
types double, integer and char and that Java and SQL procedures can handle decimal types. A 
developer is therefore able to confirm that the call to SQL from SQU for a stored procedure having 
OUT parameters of data type double, decimal, integer and char (255) will be able to be implemented 
and that the outPararneter subroutine and a decirnalType subroutine will provide mfbrmarion 
regarding the interoperability of the APIs in question. 

The developer therefore is able to make use of the Java language sample source code in SQLJ 
provided in the subroutines section of the source code sample file (corresponding to subroutine 
section 26 in Figure 2). 

An example of such a sample subroutine is set out below: 
25 public static double outParameter (Connection con) throws 
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SQLException 
{ 

double median = 0; 
try 

{ 

int outErrorCode = 0; 

String outErrorLabel « HH ; 

String procName - "OUT_PARAM"; 

//call the stored procedure 

System-out prinUn ("\nCall stored procedure name " + 
procName); 

#sql { CALL OUT_P ARAM( :out median, :out outErrorCode, :out 
outErrorLabel) }; 

if {outErrorCode = = 0) 
{ 

Systemx>utprintIn(procName + " completed successfully"); 
Systcm.out.println ("Median salary returned from " + 
procName + " - " + median); 

j 

else 

{ // stored procedure {ailed 
Systerrtoutprintln (procName + " fiuled with SQLCODE " 

+ outErrorCode); 
System.out.println (procName + " failed at " + 

outErrorLabel); 

} 

) 

catch (SQLException sqle) 
CA9-2000-0018 9 
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{ 

System.outprintln($qle); 

} 

return (median) ; 

} 

This sample oode acts as a template or model thai is available for the developer to use in creating 
the client application in SQU. The developer will then customize the cample code found in the 
subroutine section of the source code sample file. An example of such customized code is set out 
below: 



10 



public static double outPaiameter (Connection con) throws SQLExocption 

{ 

double median = Q; 
try 

15 { 

int outEiTOiCode - 0; 

String outErrorLabel - 

String prosName - "MY_NEW_PROC"; 

20 //declare and initialize output variable 

BigDccimal outDccimal - new BtgDecunal ("0.00") 

//call the stored procedure 

System.ouLprintln ("\nCall stored procedure name " + pTOcName); 
23 #sql { CALL MY_NEW_PROC (rout median, rout OutDccimal, rout 

outErrorCode, rout outErrorLabel) }; 

if (outErrorCode - - 0) 
CA9-200CMX)I8 10 
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{ 

Systcm.out.prinlln(piocName + " completed successfully 11 ); 
Systaa-outprintln ("Median salary returned from * + procName + 
*-"+ median); 

5 System.out.println ("Decimal value returned from " + procName + 

" = 0 + outDecimal); 

) 

else 

{ // stored procedure failed 
10 SystcuLout.printbi(procName + " foiled with SQLCODE 

outEnoxCode); 

System.out.prinUn(pTOcNaTne + " failed at " +owtErrorUbel); 

} 

} 

15 catch (SQLExceptxon sqle) 

{ 

Systenvoutprintla (sqle); 

} 

return (median) ; 
20 } 

As will be seen, the method defined has been customized to refer to MY NEW PROC and the 
output variable outDecimal is defined in the line "BigDecimal outDecimal - new BigDccrmal 
( n 0.00 M );" This initialization is taken from the decimal type subroutine defined in the subroutines 
section of the source code (not shown). 

25 As will be appreciated, the customization carried on ihe sample source code may well be 
considerable to meet the requirements of the developer in coding ihe client application. However, 
the information that the communication between the client and server is able to be successfully 
carried out. is presented to the developer in a useful manner. The developer is also able to use the 
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source code sample as a basis for the cliem application code which is being developed. The 
developer will have &a assurance that the call from the client API to the server API will execute 
correctly, by following the source code samples provided in die preferred embodiment 

Although a preferred embodiment of the present invention has been described here in detail, it will 
be appreciated by those skilled in the art, that variations may be made thereto. Such variations may 
be made without departing from the spirit of the invention or the scope of the appended claims. 
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The embodiments of the invention in which an exclusive property or privilege Is claimed are 
defined as follows: 



1. A computer system development tool for managing the mteroperabUity of differing 
application program interfaces, the computer system comprising a source code sample file 

5 written for a first application program interface and comprising subroutines defining 

successful interopcration with a second application program interface. 

2. The computer system development tool of claim 1 in which the source code sample file 
further comprises a conditional statement section comprising source code reflecting the 
applicability of the subroutines in the subroutine section to the permutations of client 

10 application program interface and server application program interface interoperarion. 

3. The computer system development tool of claim 2 further comprising an index section 
comprising entries referring to the source code logic blocks in the conditional statement 
section. 

4. A computer system development tool for managing the interoperability between a set of 
l5 dicnt applications and a set of server applications where each of the set of client 

applications, and each of the set of server applications, is written to conform to a selected one 
of a set of application program interfaces, the computer system development tool comprising 
a collection of source code sample files, each of the source code sample files conforming to 
a target one of the set of client application program interfaces and comprising 

20 a subroutine section having subroutines exemplifying successful ifttcro Deration between 

the target client application program interface and each of the set of differing server 
application program interfaces, 

a conditional statement section comprising source code reflecting the applicability of the 
subroutines in the subroutine section to the permutations of client application program 
25 interface and server application program interface interoperation, and 
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an index section comprising an index of the subroutines in the subroutine section. 

5. The computer system development tool of claim 4, further comprising a set of server side 
source code files for interaction with the subroutines of the source code sample files to 
demonstrate the interoperation of the subroutines of the source code sample files with the 

5 server application program interfaces. 

6. A computer pi o g t am product comprising a computer usable medium having computer 
readable program code means embodied in said medium fox use in managing the 
interoperability between a set of client applications and a set of server applications where 
each of the set of client applications, and each of the set of server applications, is written to 

10 conform to a selected one of a set of application program interfaces, said computer program 

product having 

computer readable program code comprising a collection of source code sample files, each 
of the source code sample files conforming to a target one of the set of client application 
program interfaces and comprising 

1 3 a subroutine section having subroutines exemplifying successful interoperation between 

the target client application program interface and each of the set of differing server 
application program interfaces, 

a conditional statement section comprising source code reflecting the applicability of the 
subroutines in the subroutine section to the permutations of client application program 
20 interface and server application program interface interoperation, and 

an index section comprising an index of the subroutines in the subroutine section. 

7. The computer program product of claim 6, the computer readable program code further 
comprising a set of server side source code files for interaction with the subroutines of the 
source code sample files to demonstrate the interoperation of the subroutines of the source 
25 code sample files with the server application program interfaces. 
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